home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / bgp / bgp-minutes-89july.txt < prev    next >
Text File  |  1993-02-17  |  7KB  |  221 lines
  1. Interconnectivity Working Group
  2. Chairperson:  Guy Almes/Rice
  3.  
  4.  
  5.  
  6.  
  7.  
  8. CURRENT MEETING REPORT
  9. Reported by Guy Almes
  10.  
  11.  
  12.  
  13. AGENDA
  14.  
  15.  
  16.    o Tuesday afternoon:  Open meeting to do a review of concept with other
  17.      IETFers and obtain feedback on the appropriateness of our objectives.
  18.  
  19.    o Tuesday evening:  Work on MIRA Architecture.
  20.  
  21.    o Wednesday morning:  Work on BGP Usage.
  22.  
  23.  
  24. ATTENDEES
  25.  
  26.  
  27.        1. Almes, Guy/almes@rice.edu
  28.  
  29.        2. Breslau, Lee/breslau@jerico.usc.edu
  30.  
  31.        3. Brim, Scott/swb@devvax.tn.cornell.edu
  32.  
  33.        4. Burgan, Jeffrey/jeff@nsipo.nasa.gov
  34.  
  35.        5. Carter, Glen/gcarter@ddn1.dca.mil
  36.  
  37.        6. Choy, Joe/choy@ncar.ucar.edu
  38.  
  39.        7. Crocker, Dave/dcrocker@ahwahnee.stanford.edu
  40.  
  41.        8. Deboo, Farokh/fjd@bridge2.esd.3com.com
  42.  
  43.        9. Denny, Barbara/denny@sri.com
  44.  
  45.       10. Doo, Way-Chi/wcd@bridge2.esd.3com.com
  46.  
  47.       11. Edwards, David/dle@cisco.com
  48.  
  49.       12. Enger, Robert/enger@sccgate.scc.com
  50.  
  51.       13. Estrin, Deborah/estrin@usc.edu
  52.  
  53.       14. Fair, Erik/fair@apple.com
  54.  
  55.       15. Farinacci, Dino/dino@bridge2.3com.com
  56.  
  57.       16. Fedor, Mark/fedor@nisc.nyser.net
  58.  
  59.       17. Fuller, Vince/vaf@jessica.stanford.edu
  60.  
  61.  
  62.  
  63.                                         2
  64.       18. Gerich, Elise/epg@merit.edu
  65.  
  66.       19. Grossman, Stu/grossman@score.stanford.edu
  67.       20. Hastings, Gene/hastings@morgul.psc.edu
  68.  
  69.  
  70.       21. Hedrick, Charles/hedrick@aramis.rutgers.edu
  71.  
  72.       22. Honig, Jeffrey/jch@sonne.tn.cornell.edu
  73.  
  74.       23. Ilnicki, Ski/ski
  75.  
  76.       24. Jones, Bill/jones@nsipo.arc.nasa.gov
  77.  
  78.       25. Jordt, Dan/danj@cac.washington.edu
  79.  
  80.       26. Katz, Dave/dkatz@merit.edu
  81.  
  82.       27. Kaufman, David/dek@proteon.com
  83.  
  84.       28. Lepp, Marianne/mlepp@bbn.com
  85.  
  86.       29. Lougheed, Kirk/lougheed@cisco.com
  87.  
  88.       30. Mathis, Matt/mathis@fornax.ece.cmu.edu
  89.  
  90.       31. Medin, Milo/medin@nsipo.nasa.gov
  91.  
  92.       32. Mundy, Russ/mundy@tis.com
  93.  
  94.       33. Nitzan, Rebecca/nitzan@ccc.nmfecc.llnl.gov
  95.  
  96.       34. Rekhter, Yakov/yakov@ibm.com
  97.  
  98.       35. Replogle, Joel/replogle@ncsa.uiuc.edu
  99.  
  100.       36. Roberts, Ron/roberts@jessica.stanford.edu
  101.  
  102.       37. Satz, Greg/satz@cisco.com
  103.  
  104.       38. Schoffstall, Martin/schoff@nisc.nyser.net
  105.  
  106.       39. St.  Johns, Mike/stjohns@beast.ddn.mil
  107.  
  108.       40. Steinberg, Lou/louiss@ibm.com
  109.  
  110.       41. Tsuchiya, Paul/tsuchiya@gateway.mitre.org
  111.  
  112.       42. Veach, Ross/rrv@seka.cso.uiuc.edu
  113.  
  114.       43. Volk, Ruediger/rv@germany.eu.net
  115.  
  116.       44. Wintringham, Dan/danw@osc.edu
  117.  
  118.  
  119. MINUTES
  120.  
  121. Tuesday afternoon we had an open meeting to review MIRA and BGP concepts.
  122. The notion of Route Server, the structure of MIRA, and the notion of
  123. Full-AS-Path were all discussed in detail, and comments were solicited.  Was
  124. this doable?  Would it advance the state of connectivity and
  125.  
  126.  
  127.                                         3
  128. quality/stability of Inter-AS routing?  In all these cases, we heard no
  129. substantive negative remarks.  This enabled us to proceed with our more
  130.  
  131. technical sessions, confident that MIRA and BGP would be useful if properly
  132. designed and implemented.
  133.  
  134. Tuesday evening we met to discuss detailed questions related to the
  135. implementability of MIRA.
  136.  
  137. In the general MIRA case, the Route Servers and Border Gateways are not the
  138. same machine and are not even co-located.  This makes the tasks of what EGP
  139. calls Neighbor Reachability difficult.  We agreed to focus on the case in
  140. which each Route Server shares a network, typically an Ethernet, with one or
  141. more Border Gateways of its AS.
  142.  
  143. Another technical problem relates to the transient situation in which a
  144. transit AS's Inter-AS route to a destination changes.  The AS must stop
  145. advertising its old route, then its new route must be usable and used and
  146. propagated through the Interior Gateways of its AS, and then it can
  147. advertise its new route to other ASes.  Flash updates with the AS's IGP and
  148. engineering of non-huge diameters will be key.  We returned to this issue on
  149. Wednesday.
  150.  
  151. Another issue was the determination of up/down status of the link between
  152. adjacent ASes.  In many protocols, such as RIP, there is no up/down protocol
  153. other than the receipt of routing packets; this leads to grave problems when
  154. diode situations arise.  Even in modern protocols, such as the IS-IS
  155. protocol used within the NSFnet Backbone, up/down protocols may fail.  A
  156. recent case was discussed in which a non-trivial bit-error rate existed on a
  157. serial line of the Backbone.  The rate was low enough to allow most of the
  158. (very small) packets used in the up/down protocol to get through.  The rate
  159. was large enough, however, to corrupt most large data packets, so the link
  160. was essentially useless, even though the IS-IS up/down protocol had
  161. determined the link was up.  Some of the group have concluded that the only
  162. reliable up/down protocol approach will be to use monitoring protocols such
  163. as SNMP, with careful implementations adapted to the particular kind of
  164. physical/link layers used.  During the near term, however, when such
  165. monitoring implementations are not available, a conservative approach would
  166. be to insist on colocating Route Servers on an Ethernet.
  167.  
  168. We concluded the session with a discussion of the pros and cons of
  169. separating the role of Route Server from the role of Border Gateway.  We
  170. noted that MIRA *allows* the two to be implemented within the same machine.
  171. Doing so in fact simplifies various RS-to-BG communications.  It is crucial,
  172. however, to also allow the two to be separated:
  173.  
  174.  
  175.  
  176.                                         4
  177.    o This will allow network engineers to continue to use existing Border
  178.      Gateways and still move to MIRA with separate RSes.
  179.  
  180.    o It will reduce the computational burden on the Border Gateways by doing
  181.  
  182.      Inter-AS routing functions in another computer.
  183.  
  184.    o It will allow network engineers to choose among vendors for RS
  185.      implementations.  (In the current environment, users are `captive' to
  186.      gateway vendors; we should try to reduce the extent of this.)
  187.  
  188.    o A vendor can add RS functionality to its gateway product on a schedule
  189.      of the vendor's choosing; its customers can use separate RSes during
  190.      the meantime.
  191.  
  192.    o All network engineers could support MIRA/BGP with separate RSes during
  193.      a period of time in which integrated RS/BG implementations were being
  194.      built.
  195.  
  196.  
  197. Wednesday morning we focused on the dynamics of changing Inter-AS routes.  A
  198. near-worst-case occurs when AS1 functions as a transit AS for a given
  199. destination N. AS1 uses AS2 as its next AS in routing to N, and advertises
  200. this path to AS3.  AS3, however, uses a path via AS5, and AS1 sees AS3
  201. advertising this path.  Now, due to a break in the direct AS1-to-AS2 link,
  202. AS1 wants to use AS3 as its next hop.  Before it can do so, two things must
  203. happen:
  204.  
  205.  
  206.    o AS1's neighbors must learn that AS1's old path is no longer valid.
  207.      (Otherwise a loop can form.)
  208.  
  209.    o The Interior Gateways of AS1 must learn that a Border Gateway to AS3 is
  210.      its path to N rather than the Border Gateway to AS2.
  211.  
  212.  
  213. During the time when these two things are happening, routing to N will be
  214. very difficult, and dropped packets may occur.  Careful sequencing of
  215. actions must take place in these and similar cases.
  216.  
  217. A second issue was to decide on Shortest-AS-Path-Length and Static
  218. Preferences as the methods of deciding which of several alternate AS Paths
  219. to use.  MIRA/BGP allows for future more sophisticated techniques, but we
  220. will wait a while to push these techniques.
  221.